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Bruce  J.  MacLennan 
Computer  Science  Department 
Nava]  Postgraduate  School 
Monterey,  CA  93943 


Abstract: 

This  is  the  first  report  of  a  series  exploring  the  use  of  the  Cl  programming  notation  to  prototype  a  pro¬ 
gramming  environment.  This  environment  includes  an  interpreter,  unparser,  syntax  directed  editor, 
command  interpreter,  debugger  and  code  generator,  and  supports  programming  in  a  small  applicative 
language.  The  present  report  describes  the  interpreter,  unparser,  syntax  directed  editor,  command 
interpreter  and  debugger  for  a  subset  of  the  language,  namely  arithmetic  expressions. 


1.  Introduction 

Our  goal  is  to  explore  in  the  context  of  a  very  simple  language  the  use  of  the  Cl  programming  notation 
MacLennan83,  MacLennan85|  to  implement  some  of  the  tools  that  constitute  a  programming  environ¬ 
ment.  Succeeding  reports  will  extend  the  tools  described  in  this  report*. 

The  structure  of  this  report  is  as  follows:  First  we  briefly  review  the  Q  programming  notation  for 
describing  transformations  on  relations.  Second,  we  define  a  simple  language  —  the  language  of  arith¬ 
metic  expressions.  An  abstract  syntax  for  this  language  is  defined  in  terms  of  relations.  Third,  we  dis¬ 
cuss  abstract  interpretation  of  programs  in  this  language.  Fourth,  we  modify  the  interpreter  to  accom¬ 
plish  unparsing.  Next,  we  look  at  error  recovery  and  interactive  debugging.  Finally,  we  consider  syntax 
directed  editing  of  abstract  programs. 


’  Support  for  this  reeearch  wa«  provided  by  the  Office  of  NavaJ  Research  under  contract  N00014-85- WR-240S7. 
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2.  OVERVIEW  OF  fl 


2.1  Requirements  for  a  Programming  Environment  Database 

To  understand  the  relevance  of  fi  to  programming  environments  we  begin  by  stating  the  requirements 
for  a  software  development  database.  It  will  be  required  to  store  and  interrelate  many  kinds  of  infor¬ 
mation 

—  Programs 

—  Specifications 

—  Documentation 

—  Version  Information 

—  Comments 

—  Object  Code 

—  Implementation  Hints 

—  Test  Data 

—  Test  Results 

—  Reports 

—  Runtime  Structures 

In  prototyping  tools  and  environments,  we  want  to  make  a  minimum  of  implementation  commitments. 
Hence,  it  is  convenient  to  take  a  relational  view.  This  is  because  relations  are  a  well-understood, 
implementation-independent  way  of  viewing  databases. 

2.2  RELATIONS 

We  will  view  the  computer  system  (or  network)  as  containing  a  (possibly  large)  number  of  (finite)  rela¬ 
tions.  The  number  of  relations  is  not  fixed;  new  (empty)  relations  can  be  created  by  direct  (user)  or 
indirect  (program)  request.  The  tuples  in  relations  can  contain: 


•  Values:  For  example,  numbers,  Booleans,  characters,  strings,  “pure”  lists. 

•  Objects:  Essentially  unique  IDs:  their  only  properties  are  the  relations  in  which  they  participate. 
Relations  are  themselves  objects. 

2.3  Notation 

We  use  the  notation  ‘R[z,y,  .  .  .  ,z)'  to  mean  the  tuple  ( x ,  y ,  .  .  .  ,  z)  is  in  R.  Similarly, 
‘-R(z,y,  ...  ,2)’  means  that  there  is  no  such  tuple  in  R. 

Operations  on  the  database  are  described  by  a  kind  of  production  rule: 

cause  =s>  effect 

The  effect  part  is  composed  of  a  series  of  transactions.  There  are  two  forms  for  a  transaction: 

•  R(z,y,  ...  ,2)  means  add  the  tuple  (z,y,  .  .  .  ,z)  to  R. 

•  ~'R(x  ,y ,  .  .  .  ,  2)  means  delete  the  tuple  from  R. 

The  arguments  x,  y,  ,  z  can  be  any  applicative  expressions.  They  can  also  be  procedures,  i.e., 

parameterized  database  transformations. 

The  cause  part  has  the  form: 

condition  ,  • 

The  cause  is  a  sequence  of  conditions  separated  by  commas.  Each  condition  asks  whether  certain  rela¬ 
tions  hold  certain  tuples. 

The  condition  * R(x  ,y ,  .  .  .  ,  z)’  succeeds  if  there  is  a  tuple  ( z  ,y,  .  .  .  ,z)  in  R .  On  the  other  hand, 

'-R[x,y,  .  .  .  ,z)’  fails  if  there  is  such  a  tuple  in  R  .  The  arguments  z,  y,  .  .  .  ,  z  have  the  forms: 

•  a  constant  matches  itself; 

•  a  free  variable  matches  anything,  and  becomes  bound  to  value  it  matches. 

•  an  applicative  expression  matches  its  value. 

We  consider  several  examples  of  conditions.  R(2,3)  succeeds  if  the  pair  (2,3)  is  in  R.  -'R  ( 2,3) 
succeeds  if  the  pair  (2,3)  isn’t  in  /? .  If  ‘y’  is  free  (unbound),  then  R(2,y)  succeeds  if  there  is  a  pair  of 


the  form  (2.e)  in  R ;  variable  ly'  becomes  bound  to  v.  -R(2.y)  succeeds  if  there  is  no  pair  of  the 
form  ( 2, t? )  in  R.  If  ‘y’  is  bound  to  v.  then  S(y,3)  succeeds  if  the  pair  (f,3)  is  in  S.  -5(y,3) 
succeeds  if  the  pair  (t>,3)  is  notin  S. 


An  implicit  join  is  a  rule  in  which  the  same  free  >-ariablf  appears  in  several  conditions.  For  exam¬ 


ple, 


*(2 ,»),  S(y, 3) 


succeeds  if: 


1.  There  is  a  pair  of  the  form  (2,u)  in  R 

2.  The  pair  (t>,3)  is  in  S 

It  fails,  otherwise.  Note:  There  may  be  many  pairs  of  the  form  (2,t/)  in  R.  The  join  succeeds  if  for 
one  or  more  of  them  (t>,3)  is  in  5.  Any  conjunction  of  conditions  is  allowed  in  the  cause. 

2.4  Stack  Example 

To  illustrate  these  ideas  we  show  the  fi  definition  of  a  stack  manager.  First  we  introduce  the  relations 
and  their  intuitive  meanings: 

•  Stack(s)  —  object  s  is  a  stack 

•  Con  ten ts(  r , s  )  —  the  list  z  is  the  contents  of  « 

•  Push(a,z,<)  —  a  pushes  x  on  < 

•  Pop( a , < )  —  a  pops  b 

•  Receives}  a  ,z  )  -  a  receives  x 

The  domains  of  these  relations  are  described  by  the  following  assertions  (second  order  relations).  Thus 
'Degree  (Contents,  2)’  means  that  all  the  tuples  in  Contents  have  two  elements;  ‘Domain  (list,  1,  Con¬ 
tents)’  means  that  the  first  elements  of  the  tuples  in  Contents  satisfy  the  ‘list’  predicate;  and  Indexed 
(Contents,  2)’  means  that  the  second  elements  of  the  tuples  in  Contents  are  all  unique.  Each  assertion 
is  shown  in  two  notations:  the  usual  predicate  notation  and  a  pseudonatural  notation  (Q  supports 
several  semantically  equivalent  notations:  see  [MacLennan84.  UfTord85j). 


>  Degree  (Stack,  1) 

‘Stack’  has  degree  1. 

•  Degree  (Contents,  2), 

‘Contents’  has  degree  2. 

•  Domain  (list,  1,  Contents) 

‘list’  is  domain  1  of  ‘Contents’. 

•  Domain  (Stack,  2,  Contents) 

‘Stack’  is  domain  2  of  ‘Contents’. 

•  Indexed  (Contents,  2) 

‘Contents’  is  indexed  by  domain  2. 

•  Degree  (Push,  3) 

‘Push’  has  degree  3. 

•  Domain  (Stack,  3,  Push) 

‘Stack’  is  domain  3  of  ‘Push’. 

•  Degree  (Pop,  2) 

‘Pop’  has  degree  2. 

•  Domain  (Stack,  2,  Pop) 

‘Stack’  is  domain  2  of  ‘Pop’. 

•  Degree  (Receives,  2) 

‘Receives’  has  degree  2. 

The  pop  rule  describes  how  to  pop  a  stack 
Stack  («),  Pop  (o,«),  Contents  (x,«) 

=>  -Pop  (a,*), 

-^Contents  (z  ,i ) , 

Receive  (a,  first  [ z j ) , 


Contents  (rest  [z;,  *) 


It  can  be  read  as  follows:  “If  s  is  a  stack,  a  is  popping  s.  and  z  is  the  contents  of  s.  then  a  is  not  pop¬ 
ping  s,  z  is  not  the  contents  of  s ,  a  receives  the  first  element  of  i.  and  the  rest  of  z  is  the  contents  of 

8.” 

The  push  rule  is  analogous: 

Stack  (s),  Push  (a,z,«),  Contents  )y,s) 

=?>  -T*ush  ( a ,z ,8 ), 

^Contents  ( y , « ) , 

Receive  (a,s), 

Contents  (cons  [z,y],  s) 

If  8  is  a  stack,  a  is  pushing  z  on  8,  and  y  is  the  contents  of  8,  then  a  is  not  pushing  z  on  s,  y  is  not 
the  contents  of  8,  a  receives  8,  and  the  result  of  consing  z  on  y  is  the  contents  of  e. 

2.5  Further  Notationa]  Conventions 

Notice  that  in  the  push  and  pop  rules,  conditions  found  to  hold  in  the  cause  parts  of  rules  are  often 
canceled  in  the  effect  parts.  Since  this  is  a  very  common  situation  we  introduce  the  following  cancella¬ 
tion  convention:  When  a  tuple  found  in  the  condition  is  removed  by  the  effect,  i.e.,  a  relation  that  holds 
in  the  condition  is  canceled  by  the  effect,  we  can  indicate  this  by  an  before  the  condition.  For 
example,  the  pop  and  push  rules  can  be  written: 

Stack)  e),  *Pop( a,s},  'Contents) z  ,8 ) 

=?>  Receive)  a,  firstjz'),  Contents)  rest)  z ) ,  s) 

Stack(e),  'Push)  a  ,z  ,s) ,  'Contents)  y,  8  ) 

=?•  Receive)  a  ,8  ),  Contents(cons|  z,y  ; .  t ) 

It  is  often  useful  to  limit  the  application  of  rules  by  constraints,  which  are  implemented  as  follows  The 
relation  called  ‘if  contains  the  single  value  true  Hence,  an  applicative  expression  that  evaluates  to  a 
Boolean  value  can  be  used  to  constrain  rule  application  For  example: 
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Sched  (it)-  Clock  ( t ) .  if  ( t  >  <) 


For  convenience  we  often  omit  the  if  and  write: 


Sched  (z,t).  Clock  ( t  ) .  1 t  =>  •  •  • 

We  can  summarize  all  that  we've  seen  in  the  following  (simplified)  grammar  for  the  fi  language: 

Simplified  fi  Grammar 

rule  =  cause  ==>  effect 
cause  =  cond  ,  •  •  ■ 


cond 


ret  args 


args  =  (  expr  ,  •  •  •  ) 
effect  =  trans  ,  •  •  • 
trans  =  [  ->j  rel  args 

A  complete  fi  grammar  can  be  found  in  |  MacLennan85! . 

2.6  Pseudonatural  Notation 


We  have  experimented  with  several  pseudonatural  notations  for  fi  rules  The  notation  used  in  this 
report  is  a  variation  of  that  described  in  MacLennan84:  and  ;Ufford85  .  Relations  can  be  named  by 
templates,  for  example: 


-  is  stack 

-  is  contents  of  - 

-  pops  - 

-  pushes  -  on  - 

-  receives  - 


Rules  are  written 


If  -  then  - 

with  V  or  and’  for  V  The  word  ‘given’  represents  the  cancellation  convention  Hence  the  pop 
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rule  can  be  written: 


If  5  is  stack,  given  A  pops  5.  and  given  X  is  contents  of  S 
then  .4  receives  first  of  A’,  and  rest  of  Ar  is  contents  of  5. 

The  push  rule  is. 

If  5  is  stack,  given  A  pushes  A'  on  S,  and  given  Y  is  contents  of  5 
then  A  receives  5  and  catenation  of  X  and  Y  is  contents  of  5. 

Allowing  ‘a’  ‘an’  and  ;the’  as  noise  words  and  using  words  for  variable  names  we  have: 


If  an  object  is  a  stack,  given  an  agent  pops  the  object,  and  given  a  list  is  the  contents  of  the  object 
then  the  agent  receives  the  first  of  the  list,  and  the  rest  of  the  list  is  the  contents  of  the  object. 


If  an  object  is  a  stack,  given  an  agent  pushes  a  thing  on  the  stack,  and  given  a  list  is  the  contents  of 
the  stack  then  the  agent  receives  the  stack,  and  the  catenation  of  the  thing  and  the  list  is  the  con¬ 
tents  of  the  stack. 


3.  Abstract  Structure 


For  our  example  programming  environment  we  will  use  a  very  simple  language  of  arithmetic  ex 
sions  composed  of  — .  x.  -5-.  parentheses  and  literal  integers.  A  typical  program  is: 

[  3  —  5)  x  6 

First  we  must  define  an  abstract  structure  for  representing  programs  There  are  two  kinds  of  nodes 

•  Constant  Nodes:  correspond  to  literals. 

•  Application  Nodes:  correspond  to  the  application  of  an  operator  to  its  operands 
These  nodes  and  their  interconnections  can  be  represented  by  the  relations: 

•  Con  (  E ) 

£  is  a  constant 

.  Litval  (  V,  E) 

V  is  the  literal_value  of  E- 

•  Appl  (E) 

E  is  an  application. 

.  Op  (F.  E) 

F  is  the  operator  of  E. 

.  Left  (A',  E) 

X  is  the  left _argument  of  E. 

•  Right  (  F.  E) 

Y  is  the  right _argument  of  E 
For  example,  the  program 

(3*5)  x  6 

would  be  represented  by  the  database: 


App]  (nl) 

Op(“x”,  nl) 

Left  (n2,  nl) 

Right  (n3.  nl) 

Appl  (n2) 

Op  (“-”,  n2) 

Left  (n4,  n2) 

Right  { n 5,  n2) 

Con  (n3) 

Litval  (6,  n3) 

Con  (n4) 

Litval  (3,  n4) 

Con  (n5) 

Litval  (5,  n5) 

Meaning  (sum,  “+  ”) 

Meaning  (product,  “x”) 

We  have  given  the  objects  names  (‘nl’,  ln2’,  etc.)  only  so  they  can  be  referred  to  in  our  example;  nor¬ 
mally  they  would  be  anonymous  since  the  tree  would  have  been  constructed  by  an  editor.  This  data¬ 
base  is  portrayed  in  Figure  1. 

In  defining  the  domains  of  the  various  relations,  it  will  be  convenient  to  make  use  of  the  following 
function  abbreviation.  Let  ‘Functionf  F,  D  ,R  )  ’  mean 

•  Degree(F,2), 

•  Domain}/?  ,1  ,F) , 

•  Domain(D,2,F), 

•  Indexed(F,2) . 


In  the  pseudonatural  notation  we  can  say: 


Figure  1.  Database  Representing  Abstract  Program 


‘F  is  a  function  from  D  to  R  ’  means 


Li tval 


6 


‘F  has  degree  1,  R  is  domain  1  of  F,  D  is  domain  2  of  F,  and  F  is  indexed  on  domain  2’. 


Hence,  if  we  know  that  Fun ction(  F,D  ,R) ,  that  is,  that  F  is  a  function  from  D  to  R ,  then  we  know 
that  given  any  z  in  D  there  will  be  at  most  one  y  such  that  F(y,r). 

The  domains  of  the  abstract  program  structure  relations  (in  the  pseudonatural  notation)  are  as  fol¬ 
lows: 


•  ‘constant’  has  degree  1. 

•  ‘literal  value’  is  a  function  from  ‘constant’  to  ‘integer’. 

•  ‘application’  has  degree  1. 

•  ‘operator’  is  a  function  from  ‘application’  to  ‘string’. 

•  ‘left ^argument’  is  a  function  from  ‘application’  to  ‘expression’. 

•  ‘right _argument’  is  a  function  from  ‘application’  to  ‘expression’. 
In  the  predicate  notation  this  is: 

Degree  (Con,  1) 

Function  (litval,  Con,  integer) 


Degree  ( Appl,  1) 


Function  (Op,  Appl,  string) 


4.  Evaluation 


4.1  Relations 

The  preceding  relations  define  the  abstract  program  structure.  they  are  static  (with  respect  to  program 
evaluation).  We  need  additional  relations  to  control  program  evaluation:  they  are  dynamic  (with  respect 
to  program  evaluation)  The  evaluation  relations  are 

.  Eval(E) 

E  is  evaluated 

•  Value  (  V.  E) 

V  is  the  value  of  E 

•  Meaning  (  F,  .V) 

F  is  the  meaning  of  .V 
The  domains  of  these  relations  are: 

•  Degree(Eval,l),  Domainj  expr.  1.  Eval). 

evaluated’  has  degree  1.  and  'expression’  is  domain  1  of  ‘evaluated’ 

•  Function  (Value,  expr.  integer) 

‘value’  is  a  function  from  ‘expression’  to  ‘integer’. 

Function  (M  eaning.  string,  function) 

‘meaning’  is  a  function  from  string'  to  expression'. 

Eval  and  Value  can  be  thought  of  as  attriiutcs  that  at  various  times  are  attached  to  various  nodes  in  the 
tree  In  particular,  the  Eval  attribute  on  a  node  means  that  the  evaluation  of  that  node  has  been 
requested,  but  not  serviced  The  Value  attribute  associates  a  value  with  a  node  until  such  time  as  that 
value  is  used  The  Meaning  relation  is  a  table  that  maps  the  names  of  operators  into  functions  for  per¬ 


forming  the  operations 


That  is,  if  the  Eval  attribute  arrives  at  a  constant  node,  then  we  remove  the  Eval  attribute  (since  the 
request  has  been  serviced),  and  use  a  Value  link  to  bind  the  node’s  literal  value  to  the  node.  In  other 
words,  when  an  Eval  arrives  at  a  leaf  of  the  tree  it  is  converted  into  a  Value,  which  will  travel  back  up 
the  tree. 

The  rule  for  accomplishing  this  is  simply1: 

If  given  an  expression  is  evaluated,  the  expression  is  a  constant,  a  number  is  the  literal  value  of  the 
expression,  and  a  function  is  the  meaning  of  “lit” 

then  the  function  of  the  number  is  the  value  of  the  expression. 

This  is  expressed  in  the  predicate  notation  as: 

*Eval(£),  Con(£),  Litva!(  V,E),  Meaning(/',“lit”)  =s>  Value ( F[  V],E) 

The  function  that  is  the  meaning  of  “lit”  is  the  identity  function,  hence  the  following  simpler  rule 
would  also  work 

*Eval(£).  Con(£),  Litval(  V.E)  =*>  Va!ue(  V,E) 

We  have  used  the  more  complicated  rule  to  display  the  symmetry  between  the  evaluator  and  the 
unparser  (which  is  discussed  in  the  following  section). 


1.  The  pteudonatural  transcr'iptioo  of  the  rule*  wat  prepared  by  Robert  Ufford;  *ee  L'fford&Si 


4.3  Evaluation  of  Application  Node 


Evaluation  of  application  nodes  is  accomplished  in  two  steps.  First  there  is  a  downward  analysis  pass 
when  the  Eva!  attribute  reaches  the  node  and  is  passed  to  its  daughters.  Later  there  is  an  upward  syn¬ 
thesis  pass  when  the  Values  from  the  daughters  arrive  back  at  the  node  and  are  used  to  compute  the 
Value  for  the  node.  These  steps  can  be  visualized  as  in  Figures  2  and  3. 


If  an  expression  is  an  application,  a  string  is  the  operator  of  the  expression.  node_l  is  the  left  argu¬ 
ment  of  the  expression.  node_2  is  the  right  argument  of  the  expression,  a  function  is  the  meaning 
of  the  string,  given  number _1  is  the  value  of  node_l  and  given  number_2  is  the  value  of  node_2 
then  the  function  of  number _1  and  number_2  is  the  value  of  the  expression. 

In  the  predicate  notation: 

Appl(£),  Op(JV,£),  Left( X.E) ,  Right(y,£), 

Meaning( £,  Ar) ,  ‘Value (  U,X),  ‘Value (  V,  Y) 

=?>  Value  ( F  [U,V],  £) 

This  completes  the  parallel  evaluator  for  simple  abstract  arithmetic  expressions. 


S.  Unparsing 


S.l  Relations 

We  will  nos  use  exactly  the  same  approach  as  used  for  evaluation,  but  for  a  different  purpose  — 
unparsing  Instead  of  computing  an  integer  value  for  the  abstract  program,  we  will  compute  a  string 
value,  which  is  the  program's  concrete  representation  That  is  we  will  unparse  the  abstract  program. 
This  is  accomplished  by  changing  the  interpretation  of  the  literal  constants  and  the  primitive  operators. 

This  is  a  quite  general  approach  From  a  single  program  such  as  the  evaluator  can  generate  a 
family  of  related  programs,  just  by  changing  the  domain  of  interpretation  of  the  constants  and  operators. 
Examples  of  tools  amenable  to  this  approach  are  unparsers,  type  checkers,  symbolic  evaluators. 

The  following  relations  are  needed: 

•  Unperse  (£) 

E  is  unparsed 
(corresponds  to  Eval) 

•  Image  (5.  E) 

5  is  the  image  of  E 
(corresponds  to  Value) 

•  Template  (  7,  .V) 

T  is  the  template  for  ,V 
(corresponds  to  Meaning) 

Given  our  previous  example,  l’nparse(nl)  will  eventually  result  in 

Image  (”(  (3-5)  *  6)  ”,  nl ) 

For  simplicity  we  have  generated  an  image  that  is  fully  parenthesized 
The  domains  of  the  relations  are  as  follows 

•  Degree  (Lnparse,  1) 

‘unparsed'  has  degree  1 


•  Function  (Image  expr.  string). 

'image'  is  a  function  from  expression'  to  'string' 

•  Function  (Template,  string,  function) 

'template  is  a  function  from  string'  to  'function' 

We  also  will  make  the  following  assumptions; 

•  Assume  the  function  ‘string— int  n  '  converts  the  integer  n  into  a  string 

•  Assume  Template  (string— int.  “lit”). 

•  Assume  «  represents  string  catenation. 

•  For  operator  symbols  ,V,  assume  Template  ( F ,  Ar).  where 

F  U,V  =  “(”  *U  * N  -V 

and  .V  is  “  -  ”  or  or  “x”  or  “-r”.  Thus,  if  Template  (F,  ”),  then 

F  “3”.  “(6  x  2)”',  =  “(3  -  (6  x  2)”' 

5.2  Unparsing  Constants 

When  the  L  n parse  attribute  arrives  at  a  constant  node,  the  literal  value  is  converted  to  a  string  and 
made  the  image  of  the  node.  In  the  pseudonatural  notation  the  rule  is: 

If  given  an  expression  is  unparsed,  the  expression  is  a  constant,  a  number  is  the  literal  value  of  the 

expression,  and  a  function  is  the  template  of  “lit” 

then  the  function  of  the  number  is  the  image  of  the  expression. 

In  predicate  notation  it  is 

*1  nparse(F)  Con(F),  Litva!(  V.E),  Template)  F.E) 

=>  Image)  F  V  E) 

5.S  Unparsing  Applications 

The  arrival  of  the  unparse  attribute  at  an  application  node  triggers  its  propagation  to  the  daughter 
nodes  Hence  the  analysis  rule  in  pseudonatura!  notation  is 


If  given  an  expression  is  unparsed,  the  expression  is  an  application,  node-1  is  the  left_argument  of 
the  expression,  and  node_2  is  the  right _argument  of  the  expression 
then  node _1  is  unparsed,  and  node _2  is  unparsed. 

In  predicate  notation  it  is: 

*Unparse(£),  Appl(£),  Left(A,£),  Right(  K, £7) . 

=>  Unparse  (X),  Unparse)  T) 

When  images  arrive  at  the  daughters  of  the  application,  they  are  combined  by  the  template  function  of 
the  operator  into  an  image  for  the  entire  node.  Hence  the  synthesis  rule  in  pseudonatural  notation  is: 

If  an  expression  is  an  application,  a  string  is  the  operator  of  the  expression,  node _1  is  the 
left _argument  of  the  expression,  node_2  is  the  right _argument  of  the  expression,  a  function  is  the 
template  of  the  string,  given  image _1  is  the  image  of  node _1,  and  given  image_2  is  the  image  of 
node_2 

then  the  function  of  image_l  and  image _2  is  the  image  of  the  expression. 

In  the  predicate  notation: 

Appl(£),  Op(  iV ,  £ ) ,  Left(  X.E) ,  Right(  >',£), 

Template)  F,N) ,  ‘Image)  U,  A') ,  ‘Image)  V,Y) 

Image  (£  :  V,  V, ,  £) 


This  completes  the  rules  for  the  unparser. 


6.  Information  Hieing 


The  relations  can  be  divided  into  three  domains  of  accessibility  on  the  basis  of  “need  to  knot*' 


That  is,  both  the  evaluator  and  the  unparser  need  access  to  the  abstract  structure  relations  (read-only 
access,  actually).  On  the  other  hand,  the  evaluator  needs  access  to  its  own  dynamic  relations,  but  not 
to  those  of  the  unparser.  Conversely,  the  unparser  needs  access  to  its  own  relations,  but  not  the 
evaluator’s.  These  access  restrictions  can  be  enforced  bv  the  capability  mechanism  described  in 
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7.  Error  Handling 


7.1  Error  Detection 

A  real  programming  environment  must  be  able  to  detect  errors  and  allow  the  user  to  deal  with  them. 
Let's  consider  what  happens  when  an  error  occurs.  Suppose  we  evaluate  ((3-fO)-]).  This  leads  to  the 
asse  rtion 

Value  (quotient  3,0  .  n) 

Suppose  quotient  3.0  =c-  error.  This  will  trigger  that  assertion 

V’alue  (sum  error, 1],  m) 

Lf  we  further  assume  sumjerror.lj  =>  error,  then  the  value  returned  for  the  entire  evaluation  is 
‘error’.  This  result  is  not  helpful  —  it  doesn’t  tell  us  where  the  error  occurred,  only  that  an  error 
occurred. 

One  possible  solution  is  to  suppose  the  primitive  operations  return  “error  codes”  when  something 
goes  wrong,  that  the  code  indicates  what  went  wrong,  and  that  error  codes  are  distinguishable  from 
integers  and  other  “legitimate”  values.  Then  we  can  incorporate  error  checking  into  our  interpreter. 
We  do  this  by  tentatively  attaching  the  alleged  value  to  the  node  (via  a  new  relation  called  Check)  until 
it  is  determined  whether  or  not  the  value  is  legitimate.  This  requires  the  following  additional  relations: 

.  Check  (  V,  E ) 

V  is  the  value  to  be  checked  for  E 

•  Explanation  (S,  C) 

S  is  the  explanation  of  error  C 

•  Display  ( 5) 

S  is  displayed 

•  CurrentN’ode  (£) 

E  is  the  current  node 
The  domains  of  these  relations  are: 


Function  (Check,  expr.  integer) 

Function  (Explanation,  errorcode  string). 

Degree  (  Display.  1 ) . 

Domain  (string.  1.  Display) 

We  then  need  to  modify  the  second  (upward  or  synthesis)  rule  for  applications.  It  is  replaced  by  these 
three  rules. 

Appl (£).  Op(  X  .E) .  Left(  X.E) ,  Right  (  Y.E), 

Meaning!  F, X).  ’Value)  U.X),  ‘Value)  V,  Y) 

=>  Check  (F  !  U,  V],  E) . 

‘Check)  W,E),  if  (integer;  PFj)  =>  Value)  W,E). 

‘Check)  FV' , £■ ) ,  Explanation(5,  W), 

*Current.\ode(-  ),  if  (errorcodej  tV:) 

Display  {5 },  CurrentNode ( E) . 

The  first  rule  tentatively  attaches  F[  U ,  V]  to  the  application  node  via  Check.  If  the  value  of  F  V ,  V'  is 
an  integer,  then  the  second  rule  converts  the  Check  connection  to  a  Value  connection  to  reflect  the  fact 
that  the  value  is  bona  fide  On  the  other  hand,  if  the  value  of  F\U,Vj  is  an  error  code,  then  evalua¬ 
tion  is  stopped  (since  no  Value  is  attached  to  the  node),  the  offending  node  is  recorded  (in 
CurrentNode),  and  an  explanation  of  the  error  code  is  displayed. 

In  the  pseudonatural  notation  these  rules  are: 

If  an  expression  is  an  application,  a  string  is  the  operator  of  the  expression,  node_J  is  the 
left  _argument  of  the  expression,  node_2  is  the  right  ^argument  of  the  expression,  a  function  is  the 
meaning  of  the  string,  given  numberl  is  the  value  of  node _1 ,  and  given  number_2  is  the  value  of 
node_2  then  the  fun"tion  of  number _1  and  numberj  is  the  value  to  be  checked  for  the  expression. 

If  given  an  alleged  value  is  the  value  to  be  checked  for  an  exp  ession,  and  the  alleged _value  is  an 
integer  then  the  alleged_value  is  the  value  of  the  expression. 
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If  given  an  alleged_yalue  is  the  value  to  be  checked  for  an  expression,  the  alleged_v alue  is  an 
error_code.  a  string  is  the  explanation  of  the  error_eode.  and  any  jiode  is  the  current_node  then  the 
string  is  displayed,  and  the  expression  is  the  current  node. 

Thus,  if  an  erro’  value  is  detected,  evaluation  is  suspended,  an  error  message  is  issued,  and  the 
offending  node  is  recorded. 

The  alert  reader  will  realize  that  with  a  parallel  evaluator  there  is  the  possibility  of  several  errors 
occuring  concurrently.  With  the  error  checking  method  presented  above,  all  the  diagnostics  will  be 
issued  correctly,  but  CurrentNode  will  record  only  the  last  node  to  generate  an  error  A  more  elaborate 
system  would  place  all  error  nodes  in  a  two  place  relation  ErrorNodes  such  that 

ErrorNodes  (£\C) 

means  that  node  E  generated  error  code  C.  It  is  then  necessary  to  have  a  command  for  removing  a 
node  from  ErrorNodes  and  making  it  the  CurrentNode.  The  detailed  implementation  is  left  as  an  exer¬ 
cise  for  the  reader. 

7.2  Suspension 

W'hat  is  the  state  when  an  error  message  is  sent?  There  may  be  parallel  computations  in  progress,  but 
since  no  Value  has  been  provided  for  E.  the  evaluation  cannot  complete.  It  is  suspended,  waiting  for  a 
value  for  E. 

There  are  several  possible  actions: 

1.  Supply  a  value  for  the  offending  node  and  let  evaluation  continue  E.g  *. 

CurrentNode  (£)  =>  Value  (0,£): 

2.  Unparse  the  offending  node  to  find  the  problem: 

CurrentNode  (  E)  Unparse  (E); 

CurrentNode  (£),  *Imagc  (S,£)  =*>  Display  {5}; 


We  show  the  rule  that  would  be  typed  in  U  command  mode  to  effect  the  desired  error  recovery  action. 


3.  Investigate  neighboring  nodes  (e  g.,  the  divisor): 


*CurrentNode  (£).  Right  (  Y,E)  =>  C  urrentNode  (  Y) ; 

—  un parse  as  above 

4.  Reevaluate  the  dividend  and  supply  a  default  value  for  the  divisor.  E.g., 

CurrentNode  (E).  Left  (X,E)  =*  Eval(X); 

CurrentNode  (£),  Right  (Y,E)  =>  Value  ( 1,  K) ; 

5.  Abort  evaluation  by  clearing  out  all  Eval,  Value  and  Check  tuples: 

*Eval  (£)==>  ; 

‘Value  (  V,E)  =>  ; 

‘Check  [V,E]  =>  ; 


All  these  functions  (and  more)  could  be  provided  as  commands  in  a  programming  environment.  In  the 
next  section  we  will  investigate  a  command  interpreter  that  permits  debugging  actions  such  as  these. 


8.  Command  Interpreter 


In  this  section  we  will  describe  a  simple  command  interpreter  in  D  rules  This  command  interpreter 
will  permit  the  interactive  evaluation  and  unparsing  of  (already  entered)  abstract  programs,  in  addition 
to  various  debugging  and  error  recovery  activi'ies. 

We  assume  the  existence  of  a  relation  called  Command  that  contains  the  last  string  or  keystroke  (we 
don’t  care  which)  typed  on  the  keyboard  We  will  use  boldfaced  identifiers  such  as  evaluate  to 
represent  commands;  these  identifiers  could  be  bound  to  strings,  key  codes,  menus  coordinates,  etc. 

First  we  consider  the  evaluate  command:  its  intended  effect  is  to  request  evaluation  of  the  current 
expression,  which  might  be  the  entire  program  or  some  subexpression  of  it.  This  command  is  imple¬ 
mented  by  the  following  two  rules 

‘Command  (evaluate).  CurrentNode(  E)  =r>  Eva!  (£),  Pendant  (£). 

‘Pendant  (£).  ‘Value  (  V,£)  =^>  Display  (strings  int  V ;}. 

The  first  rule  detects  the  evaluate  command  and  requests  evaluation  of  the  expression.  That  an  evalua¬ 
tion  is  in  progress  is  recorded  in  the  Pendant  relation  When  a  value  arrives  at  the  pendant  node,  it  is 
displayed  by  the  second  rule. 

The  auxiliary  relation  Pendant  can  be  eliminated  by  using  fl ’s  sequential  mechanism; 

‘Command  (evaluate).  Current.Node  (£) 

=t>  {  Eval  (  £): 

‘Value  (V.E)  =>  Display  {string— ini  V]  }  }. 

The  commands  in  the  curly  braces  are  evaluated  in  order.  Thus  the  tuple  is  asserted  to  Eval  before  the 
second  rule  waits  for  a  tuple  in  Value. 

The  val  command  is  used  to  explicitly  attach  a  value  to  a  node.  This  might  be  used  during  error 
recovery  to  allow  evaluation  to  proceed  in  the  face  of  errors.  The  command  makes  use  of  an  additional 
relation  Argument  which  holds  a  string  value  typed  in  from  the  keyboard.  We  can  imagine  this  work¬ 
ing  as  follows:  The  user  types  ‘254’  and  strikes  the  val  key.  This  causes  the  string  “254”  to  be  put  n 
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the  Argument  relation  and  the  key  val  to  be  put  in  the  Command  relation  The  rule  for  processing  the 
val  command  is: 

*Command(vaI).  ‘Argument)  V') .  CurrentNode(£) 

=>  Value  (ini'- string  V  ,£). 

The  show  command  requests  the  current  expression  to  be  unparsed  and  displayed.  It  is  implemented 
by: 

‘Command  (show),  CurrentNode  (£) 

==>  {  Unparse  (  E) ; 

‘Image  (S,£)  =>  Display  {5}}. 

It  is  also  useful  to  have  commands  for  moving  within  the  abstract  program  structure.  The  in  command 
“zooms  in”  by  focusing  on  the  left-argument  of  the  current  expression: 

‘Command  (in),  ‘CurrentNode  ( E ),  Left  (X,E) 

==>  CurrentNode  (.A). 

Thus  the  in  command  shifts  the  focus  from  the  current  node  to  the  left-argument  of  the  current  node. 

The  next  command  shifts  the  focus  from  the  left  argument  of  an  application  to  its  right  argument. 

‘Command  (next),  ‘CurrentNode  (X),  Left  (X,E),  Right  (  Y,E ) 

=£■  CurrentNode  (  V) . 

In  the  pseudonatural  notation  this  is  expressed: 

If  given  next  is  the  command,  node_]  is  the  current_node.  node_l  is  the  left _argument  of  an 
appl  _node,  and  node_2  is  the  right_argume  nt  of  the  appl_node  then  node_2  is  the  current  jiode. 

Analogous  commands  are  prev.  which  shifts  from  the  right  argument  to  the  left  argument,  and  out 
which  “zooms  out”  from  either  the  left  of  right  argument  to  the  entire  application 

For  debugging  it  is  useful  to  be  able  to  abort  a  suspended  evaluation.  This  is  accomplished  by  clear¬ 
ing  out  the  Eva!,  Check  and  Value  relations: 
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Command  (abort)  ’Eval  (£) 

else  Command  (alert).  ’Check  (  V.E)  — 

else  Command  (abort).  ’Value  (  V.£)  — • 

else  ’Command  (abort)  ==>  Displav  {‘  aborted."} 

Notice  (by  the  absence  of  an  '*')  that  the  first  three  rules  leave  abort  in  command;  hence  they  continue 
firing  as  long  as  there  axe  tuples  in  Eval.  Check  or  Value.  When  there  are  no  more  such  tuples,  the  last 
rule  cancels  the  abort  command. 

It  could  be  argued  that  these  rules  would  be  more  readable  if  the  reassertion  of  abort  were  made 
explicit,  e  g., 

’Command  (abort).  ’Eval  (£)  =>  Command  (abort) 
else  ’Command  (abort).  ’Check  (  V,E)  =>  Command  (abort) 
else  ’Command  (abort).  ’Value  (  V.E)  =s  Command  (abort) 
else  ’Command  (abort)  Display  {"aborted  ”). 

This  is  an  unresolved  stylistic  issue. 

To  illustrate  the  operation  of  the  command  interpreter,  we  present  an  example  session,  showing  the 

keys  typed  and  the  responses  of  the  system.  Assume  the  program  '((3;0)-l)’  is  alread>  created  and 

the  current  node  is  the  root  of  the  tree  The  transcript  follows 

evaluate 
zero  divide  error 
show 

(3  +  0) 

in 


evaluate 


4 


Notice  ho»  the  val  command  triggers  completion  of  evaluation  of  the  program 
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9.  Syntax  Directed  Editing 


9.1  Incomplete  Programs 

In  this  section  we  develop  a  syntax  directed  editor  for  this  simple  language  Since  for  editing  we  need 
to  be  able  to  represent  incomplete  programs  we  will  add  a  new  node  type.  Undef  .  representing  a  pan 
of  the  program  that  either  has  not  yet  been  entered  or  has  been  deleted 

ezpr  =  Con  _  Appl  _  Undef 

Next  we  must  modifv  Eva!  and  Unparse  to  deal  with  Undef  nodes: 

"Eval(E)  Undef(E).  *Curre  ntNode  ( -  )  Display{‘  Incomplete” },  CurrentNode(.E) 


*U  n  parse  (  E) ,  Undef)  £)  =>  Image  (“<  expr>  ”,  E). 

In  other  words,  evaluating  an  incomplete  program  will  lead  to  a  diagnostic  message  and  a  suspended 
evaluation.  Unparsing  an  incomplete  program  will  show  ‘<  expr>  ’  in  place  of  the  missing  subexpres¬ 
sion. 

9.2  Editor  Commands 


VV  e  will  want  next  to  shift  to  the  next  (to  the  right)  subexpression: 


We  will  want  prev  to  shift  to  the  previoss  (to  the  left)  subexpression: 


It  will  be  convenient  to  have  root  to  shift  to  the  root  of  the  program  tree 

Furthermore,  we  will  want  all  of  these  movement  commands  to  show  us  the  new  current  expression  by 
un  parsing  it. 

We  will  also  need  a  begin  command  to  initialize  the  editing  session  with  an  empty  tree: 


0 


g  u.nde( 


We  will  want  to  be  able  to  delete  a  node: 


And  we  will  want  to  be  able  to  insert  a  literal  value,  by  ‘n 


rt 


Finally  we  will  need  the  operator  commands.  -  .  x,  -y.  for  creating  application  nodes: 


The  predicate  form  for  the  in  command  rule  is' 

*Command(in),  “Current.Nodef  E) ,  LeftfA’.E) 
=t>  CurrentNode(  A"),  Command(show) 


This  is  the  same  as  the  version  discussed  n  the  previous  section,  except  that  we  have  automatically 


issued  a  show  command 


In  the  pseudonatural  notation  the  in  rule  is 

If  given  "in"  is  the  command,  given  an  expression  is  the  current _node.  and  a  node  is  the 
left  argument  of  the  expression 

then  the  node  is  the  current_node.  and  ‘‘show”  is  the  command 

The  out  command  is  analogous,  except  that  there  are  two  rules  to  handle  the  two  possible  paths  back  to 
the  parent: 

’Command(out),  “CurrentNode)  X) ,  Leftl^.E) 

==s  CurrentNode(£’) ,  Command(show) . 

‘Command(out),  “CurrentNode)  K),  Right (  Y,E) 

==>  CurrentNode)  E) ,  Com  man d( show) . 

The  next  and  prev  commands  are  similar. 

The  delete  command  is  implemented  by  breaking  the  current  node’s  connections  with  its  descen¬ 
dants  and  changing  its  type  to  Undef,  There  are  three  cases  depending  on  whether  the  node  is  a  con¬ 
stant,  application  or  already  undefined  node: 

*Command(delete),  CurrentN'ode(£),  *Con{E),  “Litvalj  V,E) 

=£•  Undeffls),  Command(show) . 

“Command(delete),  CurrentN’ode(.E') , 

*APP1(£),  “Op (\,E),  *Left(A',£),  Right (Y,E) 

=>  Undef(£),  Command) show) . 

“Co  mm  and  (delete).  CurrentNode)  E),  Lndef(£) 

=>  Display{“aJready  deleted” }. 

Note  that  subtrees  are  not  disassembled,  hence  they  could  be  reused  (say  by  a  move  command) 

There  are  two  rules  to  implement  the  #  command  The  first  one  is  to  create  a  constant  node  with  a 
given  literal  value: 
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'Com  man  d(  "  «  " ) .  ’Argument!  1') .  if  ( integer)  l’) ) .  Current  Node  (  £’)  *l"ndef(  E) 
=>  Con(£)  Litval(  WE).  Comm  and  ( show) . 


The  other  rule  handles  the  case  where  the  current  node  is  already  defined;  we  require  a  node  to  be 
deleted  before  it  can  be  replaced: 

’Command! "  *" ) .  ’Argument)  V') .  Current.Nodef  E) .  -L’ndef(£) 

—  Display  {"defined  node"}. 

Next  we  consider  that  commands  for  creating  application  nodes.  If  the  user  types  *-  ’  then  we  must 
create  an  Appl  node  with  two  undefined  daughters  and  a  1  —  ’  for  the  operator: 

*Command(“-r-  ”) ,  *CurrentNode(£) ,  *Undef(£),  *Avail(Af,  Y) 

=»  Appl (£),  Op(“^  ”,£),  Left(  Ar, £) ,  Rightf  Y,E), 

Undef(A’),  Undef(y'),  Current.\ode(  X) . 

Here  we  have  assumed  that  Avail  contains  an  indefinite  supply  of  unused  objects;  objects  are  allocated 
by  a  system  procedure  in  the  McArthur  interpreter.  Also  notice  that  the  focus  is  automatically  shifted 
to  the  left  argument  of  the  new  application. 


It  would  be  somewhat  inconvenient  to  repeat  the  above  rule  for  each  of  the  four  operators.  Also  we 
would  need  four  rules  for  detecting  already  defined  nodes.  Fortunately  we  can  use  the  applicative 
features  of  fl  to  make  one  rule  handle  all  four  operators: 


’Command(/),  member  I /,  [“+  ”,  “x”,  “*”]], 

*CurrentNode(£),  *Undef(£),  *Avail(*,  Y) 

-=>  Appl(£),  Op(/,£),  Left(A’,£),  Right(  Y,E),  Undef(.Y).  Undef(T).  CurrentNode( A') . 


Already  defined  nodes  are  handled  by: 


’Command!/),  member  /,  '”+  ”,  “x”,  ‘‘4”|  ,  Curre  nt.Node(  £) ,  -Undef(£) 

=c>  Display{‘‘defined  node”}. 

The  begin  command  is  implemented  by  creating  a  tree  containing  a  single  undefined  node: 


Command!  begin),  *Current.\ode(  -  ),  *Avail(£)  Root(£),  l’ndef(£  . 


The  root  command  is  simple  since  the  Root  relation  holds  the  root  of  the  tree  (set  by  the  begin 


command) 

’Co  mm  and  (root),  ‘CurrentNodef—  ).  Root  {E) 

==>  CurrentNode(  E) .  Com  mand(show) . 

A  typical  session  will  illustrate  operation  of  the  syntax  directed  editor.  Our  goal  will  be  to  construct  the 
program  ‘(3-yO)  — 1’  and  change  it  to  ‘(3-91)  — 1\  We  show  commands  on  the  left  margin,  and  responses 
indented: 

begin 
<  expr> 


m 


3  # 

next 
<  expr> 

0  # 
out 
(3-5-0) 
out 

( ( 3-9- 0 )  *  <  expr> 

in 

( 3-5-0) 

next 


<  expr> 


root 


( (3-rO)  -  1) 
evaluate 
zero  divide  error 
show 
(3-0) 
in 

3 

next 

0 

delete 
1  # 
root 

((»+!)  +  !) 

abort 

aborted. 

evaluate 

4 

This  is,  of  course,  a  very  simple  system  for  a  very  simple  language.  But  it  illustrates  the  ideas  of  a  pro¬ 
gramming  environment.  A  version  of  this  system  that  executes  correctly  under  the  McArthur  inter¬ 
preter  McArthur84  is  shown  in  the  appendices. 

9.J  Permissions 

We  review  the  access  to  the  various  relations  needed  by  the  various  tools: 

•  Editor  —  can  read  and  update  program  structure  relations  (Con,  Litval,  etc.).  CurrentNode.  Root 
and  evaluator  and  un parser  relations  (Eval,  Check,  Value,  Unparse,  Image). 


Evaluator  -  can  only  read  program  structure  relations,  can  read  and  update  evaluation  relations 
(Eval,  Check  and  Value);  can  update  CurrentNode  and  Display:  can  read  Meaning  and  Explanation 


•  Un parser  —  can  only  read  program  structure  relations;  can  read  and  update  unparser  relations 
(Unparse  and  Image):  can  read  Template. 

These  rights  can  be  enforced  using  the  fi  capability  mechanism,  see  MacLennan83  or  MacLennan85 
for  a  description 

10.  Conclusions 

We  believe  that  this  report  has  shown  that  major  components  of  a  programming  environment,  albeit  in 
a  rudimentary  form,  can  be  conveniently  programmed  in  fi  .  If  this  experience  is  typical,  if  a  reason¬ 
able  programming  environment  can  be  prototyped  in  a  few  hundred  rules,  then  we  believe  that  our 
ability  to  prototype  software  will  have  been  much  enhanced.  Succeeding  reports  in  this  series  will 
further  investigate  this  hypothesis  by  expanding  the  capabilities  of  the  prototype  programming  environ¬ 
ment. 
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APPENDIX  A  Prototype  Programmi;  g  Environment 


Predicate  Notation  for  fl 

The  following  is  a  loadable  input  file  for  the  prototype  programming  environment  described  in  this 
report.  It  is  accepted  by  the  McArthur  interpreter  NlcArthurS4  .  which  differs  in  a  few  details  from 
the  f2  described  in  this  report  (see  MacLennan84  ).  A  transcript  of  a  test  execution  of  this  environ¬ 
ment  is  shown  in  Appendix  C. 

!  PI-1 

!  Rules  and  associated  definitions  for 

1  an  arithmetic  expression  language. 

!  Relations 

1  Program  Structure  Relations 

define  {root,  "Appl".  newrel{}}; 
define  {root,  "Op",  newrel{}}; 
define  {root,  "Left",  newrel{}}: 
define  {root,  "Right",  newrel{}}; 
define  {root,  "Con",  newrel{}}; 
define  {root,  "Litval",  newrel{}}; 

!  Evaluation  Relations 

define  {root,  "Eva!".  newrel{}}: 
define  {root,  "Check".  newrel{}}: 
define  {root,  "Value",  newrel{}}; 
define  {root,  "Meaning",  newrel{}}; 
define  {root,  "Explanation",  newrel{}}; 

!  Un parser  Relations 
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define  {root.  "Lnparse''.  newrel{}}: 
define  {root.  "Image".  newrel{}}'. 
define  {root.  'Template".  newrel{}}: 

!  Command  Interpreter  Relations 

define  {root,  "Command",  newrel{}}; 
define  {root,  "Argument".  newrel{}}; 
define  {root.  "Root",  newrel{}}; 
define  {root,  "Undef",  newrel{}}; 
define  {root,  "CurrentNode",  newrel{}}; 

define  {root,  "EvalPending",  newrel{}}; 
define  {root,  "Sho wPending",  newrel{}}; 
define  {root,  "Create Appl",  newrel{}}: 
define  {root,  "Create Root".  newrel{}}; 
define  {root,  "Script",  newrel{}}; 
define  {root,  "PendScript",  newrel{}}. 

!  Functions 

fn  Id  x  :  x; 
fn  Sum  x.y  :  x  —  y: 
fn  Dtf  x,y  :  x  -  y: 
fn  Product  x,y  :  x  *  y; 
fn  Quotient  x.y  : 

if  y  —  0  ->  "error".  1 
else  x  y; 


fn  IsErrorcode  w  : 


if  TsList  w  w  =  Nil->  Nil 
else  first  w  =  "error": 

fn  upSurrt  x.y  :  —  x  —  "  —  "  —  v  —  ") 

fn  up!) if  x.y  :  -  x  -  "  -  "  -  y  - 

fn  upProd  x.y  :  "( "  -  x  -  "x  "  —  y  — 
fn  upQuot  x,y  :  —  x  -  "  "  —  y  — 

!  Built-in  Tables 

Meaning  (Sum,  ") ; 

Meaning  (  Dif,  ; 

Meaning  (Product,  "x"); 

Meaning  (Quotient, 

Meaning  (Id,  ’lit"); 

Template  (upSum,  "); 

Template  (upDif, 

Template  (upProd,  "x"): 

Template  (upQuot, 

Template  (int_str,  'lit"); 

Explanation  ("incomplete  program",  "error", 
Explanation  ( 'Vi  i  vis  ion  by  zero",  "error",  1  ’ ) . 

!  the  Rules 

definefroot.  "PIlRules", 

<  < 

!  Evaluator  Ru les 

!  Constant  nodes 


rr  ■  i  »■  f-  V?  9*  1  ■  U«  ^  t1  ■  t«  ^  !■  U^'T*  «■  V  »  g  ■  'J'."  J1 


if 'Eval(e).  Con(ej.  Litval(v.e).  Meaning(f.  ’'lit”) 

->  Yalue(f  v  .  e) : 

'  Appl  nodes 

if  *Eval(e),  Appl(e).  Left(x.e).  Right ( y .e ) 

->  Eval(x).  Eval(y): 

if  *Vaiue(u,x).  "Value ( v , y j .  Appl(e).  Op(n.e).  Left(xe)  Right(y.e).  Meaningff.  n) 
->  Check(f  u,v  ,  e) : 

!  Error  Checking 

if  *Check(w.  e).  ’IsErrorcode  w 
->  Value (w.  e); 

if  *Check(w,  e),  IsErrorcode  w  ,  Explanations,  w),  "CurrentN’ode(q) 

->  displayn  {s}.  Current.N'ode(e); 

!  Un parser 

!  Constant  Nodes 

if  "Unparse(e).  Con(e),  Litvai(v.e).  Templatejf.  "lit") 

*  >  Image(f  v  .  e); 

Identifier  nodes 

1  Appl  nodes 

if  "Unparseje),  Appl(e),  Left(x.e),  Right(y.e) 

->  Unparse(x).  Unparse(y); 

if  *Image(u.x).  *lmage(v,y).  Appl(e),  Op(n,e).  Left(x.e).  Right(y.e).  Templateff.  n) 
->  Image(f  u,v  ,  e); 
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'  Command  Interpreter  Rules 

'  evaluate  Command 

if  'Command!  "evaluate").  Current \ode(  E) 

-  -  Eval(E).  EvalPendtng)  E) . 

if  'Value(V.E).  'EvalPending(  E) 

->  displays  {V}: 

1  return  Command 

if  ’Command)  "val") .  'Argument!  V) .  CurrentNode(  E) 

->  Value(Y.E); 

!  show  Command 

if  'Command)  ''show") .  CurrentNode(  E) 

->  Unparse(E) .  ShowPendingf  E): 

if  'lmage(S.E).  'ShowPending(E) 

->  disp)ayn{S}; 

!  abort  Command 

if  Command!  "abort") ,  'EvalJE)  ->  ; 
if  Command)  "abort") ,  *Value(Y,E)  ->  ; 
if  Command)  "abort") ,  *Check(Y,E)  ->  ; 

if 'Comm  and(  "abort") .  ~Eval(E),  *Value(V,E)  ->  displayn{"aborted"}; 
1  Handle  incomplete  program 


if  'Eval(E).  Undef(E).  'CurrentNode(Q) 


displavn  |  'Tn'i.m  plete")  Curre  rit  Node  I  E) 


if  "Cnparsef  L)  l'ndef(E) 

Im age  (  "•  e xpr  •  "  E) 

1  Syntax  Directed  Editing 

1  in  Command 

if  'Conim  and(  "in")  "CurrentNodef  E) ,  Left(X.E) 

- >  CurrentNode(X) .  Com mand(  ’’show") 

if  "Commandfout") .  "CurrentNodef  X) .  Left(X.E) 

->  CurrentNodef  E) .  Command)  "show") ; 

if  "Commandfout"),  "CurrentNodef  Y).  Rightf  X  .  E) 

->  CurrentNodef  EE  Command)  ''show")  , 

1  next  Command 

if  "Command)  "next") ,  ’CurrentNode(X).  Left(X.E),  RightfY.E) 

->  Curre  ntNodef  Y) ,  Com  mandf  "show") ; 

1  prev  Command 

if  "Commandf  "prev") ,  "CurrentNode(Y),  Right  ( X  .  E) .  Left(X.E) 

->  CurrentNode(X) ,  Command)  "show") ; 

1  delete  command 

if  "Commandf  '^delete") ,  CurrentN'ode(E).  "Con(E),  "Litval(VE) 

->  Undef(E),  Com m and) "show") ; 

if  "Comm andf 'delete ") ,  CurrentNodef E) .  "Appl(E).  "Op(N.E).  "Left(X.E).  Right(X.E) 


Undef(E).  Commandfshow"); 


if  ’Command)  "delete'') .  Curre n t Node (  E) .  L'ndef(E) 


->  displayn  (  "already  deleted") . 

1  *  Command 

if  ’Comm  and)  "=") .  ’Argument)  V) .  Islnt  V  .  CurrentNode)  E) .  ’lndef(E) 

->  Con(E).  Litval(\  E).  Comm  and)  "show") ; 

if  “Command)  "=") .  ’Argument)  V) .  CurrentNodejE).  ’Undef(E) 

->  displayn)  "defined  node"); 

!  —  ,  x  ,  /  Commands 

if  ’Command(op),  member  'op.  ",  "x".  "/'C,  ’Curre  ntNode  ( E) ,  ’Undef(E) 

->  Create Applfop.  E.  new-objl),  newobjQ); 

if  ’Create A ppl) op.E. X.  Y) 

->  Appl(E).  Op)  op.E) .  Left)  X,  E) .  Right(Y.E) ,  Undef(X),  Undef(Y),  CurrentNode(X) 

if  ’Command(op),  member  op.  "x",  "/"  ,  CurrentNode)  E) ,  ""L’ndef(E) 

->  displayn ( "defi ned  node"); 

!  begin  Command 

if  ’Comm  and)  "begin") .  ’CurrentNode)  Q) 

->  CreateRoot(newobj)}) : 

if  ’CreateRoot)  E) 

->  Root(E).  Indef(E),  Current  Node)  E) : 

'  root  Command 

if  *C  >mm  and)  "root") .  ’CurrentN'ode(Q) .  Root(E) 

->  CurrentNode(E),  Command('%how"); 
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'  Test  Driver 


if  *Script(  Nil)  ->  displayn{"Script  completed"} 

else  if  *Script(L).  (first  L  =  "*="  first  L  =  "val") 

->  {  displayn  {"  ...  "  -  first  rest  L  -  first  L  }. 

Command(first  L  ),  Argument!  first  rest  L  ).  PendScript(rest  rest  L 

else  if  *Script(  L ) 

->  {  displayn  {"  ...  "  -  first  L  }; 

Com m and ( first  L  ),  PendScript( rest  L  )  }: 

if  *PendScript(L),  *Command(Q)  ->  Script(L) 

>>  }. 

define  {root,  "testscript". 

"begin",  ",  "/»,  3,  "next".  0,  "out",  ’but", 

"in",  "next",  1,  ’Voot".  "evaluate",  "show",  "in", 

"next",  "delete",  V",  1,  ’Voot".  "abort",  ’’evaluate"!  }. 

!  activate  the  rules 

act{  PIlRules  }. 

CurrentNode(Nil) 

displayn  {"PI- 1  System  loaded"}. 
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APPENDIX  B:  Prototype  Programming  Environment 
Pseudonatural  Notation  for  0 

This  appendix  displays  the  prototype  programming  environment  of  Appendix  A  in  the  pseudonatural 
notation  designed  by  Robert  Ufford  Ufford85  Ufford  also  performed  this  translation  of  the  Appendix 
A  program  into  the  pseudonatural  notation. 

< 

PI-1 

Rules  and  associated  definitions  for 
an  arithmetic  expression  language. 

i 

!  Relations  ! 

!  Program  structure  relations  ! 

"Application"  (procedure)  is  defined  as  a  relation. 

"Operator"  (procedure)  is  defined  as  a  relation. 

"Left_argument"  (procedure)  is  defined  as  a  relation. 

"Right ^argument"  (procedure)  is  defined  as  a  relation. 

"Constant"  (procedure)  is  defined  as  a  relation. 

"Literal_value"  (procedure)  is  defined  as  a  relation. 

1  Evaluation  relations  1 

,rEvaluated"  (procedure)  is  defined  as  a  relation. 

"Checked"  (procedure)  is  defined  as  a  relation 
"Value"  (procedure)  is  defined  as  a  relation. 

"Meaning"  (procedure)  is  defined  as  a  relation. 

"Explanation"  (procedure)  is  defined  as  a  relation. 
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.'  Unparser  relations 


"L'nparsed"  (procedure)  is  defined  as  a  relation. 

'Image"  (procedure)  is  defined  as  a  relation. 

'Template"  (procedure)  is  defined  as  a  relation. 

!  Command  interpreter  relations  ! 

"Command"  (procedure)  is  defined  as  a  relation. 
"Argument"  (procedure)  is  defined  as  a  relation. 
"Root_node"  ( procedure )  is  defined  as  a  relation. 
'Undefined"  (procedure)  is  defined  as  a  relation. 
"Current_node"  (procedure)  is  defined  as  a  relation. 

"Pending_e valuation"  (procedure)  is  defined  as  a  relation. 
'Shown"  (procedure)  is  defined  as  a  relation. 

"New _application"  (procedure)  is  defined  as  a  relation. 
"New_root"  (procedure)  is  defined  as  a  relation. 

'Script"  (procedure)  is  defined  as  a  relation. 
"Pending_script"  (procedure)  is  defined  as  a  relation. 

!  Functions  ! 
function  identity  x  :  x. 
function  sum  |x,y  :  x  —  y. 
function  difference  x,y  :  x  -  y. 
function  product  x,y x  *  y. 
function  quotient  x,yj: 

if  y  =  0  then  the _list  of  the  "error_code"  and  1 
else  x  /  y. 


function  error  code  W  : 


if  W  (predicate)  is  not  ajist  V\  -  Nil  then  Nil 
else  the  first  (function)  of  \V  -  "error_code" 

function  sum  _tetnp!ate  x.y  "( "  -  x  -  "  -  "  -  y  -  ")". 
function  difference  template  x.y  "( "  -  x  -  "  -  y  -  '*) 

function  product_tem  plate  x.y  :  "( "  -  x  -  "  x  "  -  y  - 
function  quotient  _template  x.y  "( "  —  x  -  "  "  —  y  — 

I  Built-in  tables  ! 

Sum  is  the  meaning  of  " 

Difference  is  the  meaning  of 
Product  is  the  meaning  of  "x" 

Quotient  is  the  meaning  of  "/". 

Identity  is  the  meaning  of  'lit". 

Sum  Jem  plate  is  a  template  for  "-  ", 

Difference_template  is  a  template  for 
Prod uct_tem plate  is  a  template  for  "x". 

Quotient_tem  plate  is  a  template  for 
String_notation  is  a  template  for  "lit". 

"Incomplete  program"  is  an  explanation  for  the _list  of  error_code  and  0 
"Division  by  zero"  is  an  explanation  for  th e _ list  of  error  jrode  and  1. 

!  Noise  words  ! 

"Must"  (procedure)  is  defined  as  a  noise_verb. 

"Be"  (procedure)  is  defined  as  a  noise  verb 
"Being"  (procedure)  is  defined  as  a  noise  verb. 

"Established"  (procedure)  is  defined  as  a  noise_yerb 
"Will"  (procedure)  is  defined  as  a  noise_verb. 


'Another"  (procedure)  is  defined  as  a  noise_prep. 


!  The  rules  ! 


"PI  1  j;ules"  (  procedure)  are  defined  as 


Rules 


Evaluator  rules  1 


Constant  nodes  1 


If  given  an  expression  is  being  evaluated, 
the  expression  is  a  constant, 

a  number  is  the  literal_yalue  of  the  expression,  and 
a  lit_function  is  the  meaning  of  'lit" 

then  the  lit_function  (function)  of  the  number  is  the  value  of  the  expression 


!  Application  nodes  ! 


If  given  an  expression  is  being  evaluated, 
the  expression  is  an  application, 
nodel  is  the  left_argument  of  the  expression,  and 
node2  is  the  right _argument  of  the  expression 


then  nodel  must  be  evaluated,  and 


node2  must  be  evaluated: 


If  given  value  1  is  the  value  of  nodel, 
given  value2  is  the  value  of  node2. 
the  expression  is  an  application, 
a  string  is  the  operator  of  the  expression, 
nodel  is  the  !eft_argument  of  the  expression. 
node2  is  the  right  argument  of  the  expression,  and 


an  operator  jfunotion  is  the  meaning  of  the  string 
then  the  operator_function  (function)  of  value  1  and  \alue2  must  be  checked 
for  the  expression: 

!  Error  checking  ' 

If  given  an  alleged_yalue  is  being  checked  for  an  expression,  and 
the  alleged jvalue  (predicate)  is  not  an  error _code 
then  the  alleged_value  is  the  value  of  the  expression; 

If  given  an  alleged_value  is  being  checked  for  an  expression, 
the  alleged_value  (predicate)  is  the  error _code, 
a  string  is  an  explanation  for  the  alleged_yalue  ,  and 
given  any_node  is  the  current_node 
then  the  string  (procedure)  is  displayed_with_return  and 
the  expression  is  the  current_node; 

!  Un  parser  ! 

!  Constant  Nodes  ! 

If  given  an  expression  is  being  unparsed, 
the  expression  is  a  constant, 

valuel  is  the  literal_value  of  the  expression,  and 
a  lit_function  is  a  template  for  'lit" 

then  the  lit_function  (function)  of  valuel  is  the  image  of  the  expression. 

!  Identifier  nodes  ! 

'  Application  nodes  ' 

If  given  an  expression  is  being  unparsed, 


the  expression  is  an  application. 


nodel  is  the  left  _argument  of  the  expression,  and 
node2  is  the  right  ^argument  of  the  expression 
then  nodel  must  be  unparsed  and 
node2  must  be  unparsed: 

If  given  image  1  is  the  image  of  nodel. 
given  image2  is  the  image  of  node2. 
the  expression  is  an  application, 
a  string  is  the  operator  of  the  expression, 
nodel  is  the  left _argument  of  the  expression, 
node2  is  the  right _argument  of  the  expression,  and 
an  operator_function  is  a  template  for  the  string 
then  the  operator_function  (function)  of  imagel  and  image2 
is  the  image  of  the  expression; 

!  Command  interpreter  rules  ! 

1  Evaluate  command  1 

If  given  "evaluate"  is  the  command,  and 
an  expression  is  the  current_node 
then  the  expression  must  be  evaluated,  and 
the  expression  is  pending^evaluation: 

If  given  value  1  is  the  value  of  an  expression,  and 
the  expression  is  pending_evaluation 
then  valuel  (procedure)  is  displayed _with _retu rn; 

!  Return  command  ! 

If  given  'Val"  is  the  command, 
given  valuel  is  the  argument,  and 
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an  expression  is  the  current_node 
then  value  1  is  the  value  of  the  expression. 

'  Show  command  ! 

If  given  ’’show'' is  the  command,  and 
an  expression  is  the  current_node 
then  the  expression  must  be  unparsed,  and 
the  expression  will  be  shown. 

If  given  a  string  is  the  image  of  an  expression,  and 
given  the  expression  must  be  shown 
then  the  string  (procedure)  is  displayed_with_return; 

I  Abort  command  1 

If  "abort"  is  the  command,  and 

given  an  expression  is  being  evaluated 
then  'do  nothing' 

If  "abort"  is  the  command,  and 

given  a_yalue  is  the  value  of  an  expression 
then  Ido  nothing! 

If  "abort"  is  the  command,  and 

given  a_value  is  being  checked  for  an  expression 
then  Ido  nothing' 

If  given  "abort"  is  the  command. 

an  expression  is  not  being  evaluated  and 
a  value  is  not  the  value  of  the  expression 
then  "aborted"  (  procedure )  is  displayed_with  return. 
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'  Handle  incomplete  program  ' 

If  given  an  expression  is  being  evaluated, 
the  expression  is  undefined,  and 
given  anyjiode  is  the  current_node 
then  'Incomplete"  ( procedure )  is  displayed_with_return .  and 
the  expression  is  the  current _node; 

If  given  an  expression  is  being  unparsed,  and 
the  expression  is  undefined 
then  "<  expr>  "is  the  image  of  the  expression; 

I  Syntax  Directed  Editing  ! 

!  in  Command  ! 

If  given  "in"  is  the  command, 

given  an  expression  is  the  current  jnode,  and 
nodel  is  the  left _a.rgument  of  the  expression 
then  nodel  is  the  current _node.  and 
"show"  is  the  command; 

If  given  "out"  is  the  command, 

given  nodel  is  the  current_node,  and 
nodel  is  the  left  argument  of  an  expression 
then  the  expression  is  the  current_node ,  and 
"show"  is  the  command; 

If  given  "out"  is  the  command. 

given  node2  is  the  current_node.  and 
node2  is  the  right  argument  of  an  expression 
then  the  expression  is  the  current_node.  and 
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"show"  is  the  command: 


!  next  Command  ! 

If  given  "next"  is  the  command, 
given  nodel  is  the  current _node. 
nodel  is  the  left _argument  of  an  expression,  and 
node2  is  the  right _argument  of  the  expression 
then  node2  is  the  current_node ,  and 
'^how"  is  the  command: 

1  prev  Command  1 
If  given  "prev"  is  the  command, 
given  node2  is  the  current_node, 
node2  is  the  right_argument  of  an  expression,  and 
nodel  is  the  left _argument  of  the  expression 
then  nodel  is  the  current_node,  and 
"show"  is  the  command; 

!  delete  command  ! 

If  given  "delete"  is  the  command, 
an  expression  is  the  current _node, 
given  the  expression  is  a  constant,  and 
given  a_va!ue  is  the  litera!_value  of  the  expression 
then  the  expression  is  undefined,  and 
"show"  is  the  command; 

If  given  'delete"  is  the  command, 
an  expression  is  the  current _n ode, 
given  the  expression  is  an  application, 
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given  a  string  is  the  operator  of  the  expression. 


given  node!  is  the  left _argument  of  the  expression,  and 
node2  is  the  right _argument  of  the  expression 
then  the  expression  is  undefined,  and 
"show"  is  the  command: 

If  give  "delete"  is  the  command, 

an  expression  is  the  current _node,  and 
the  expression  is  undefined 

then  "already  deleted"  ( procedure)  is  displayed_with_return 

!  #  Command  ! 

If  given  is  the  command, 
given  valuel  is  the  argument, 
value  1  (predicate)  is  an_integer, 
an  expression  is  the  current_node,  and 
given  the  expression  is  undefined 
then  the  expression  is  a  constant, 

valuel  is  the  literal_value  of  the  expression,  and 
'%how"  is  the  command: 


If  given  'V*"  is  the  command, 
given  valuel  is  the  argument, 
an  expression  is  the  current _node,  and 
the  expression  is  not  undefined 


the  string  is  a  member  of  the  _list  of  ",  "x"  and 

given  an  expression  is  the  current  jiode.  and 
given  the  expression  is  undefined 

then  the  expression  is  established  as  a  ne w_application  with  a  string 
and  an  object  and  another  object: 

If  given  an  expression  is  a  ne  w_application  with  a  string  and  nodel 
and  node2 

then  the  expression  is  an  application. 

the  string  is  the  operator  of  the  expression, 
nodel  is  the  left _argument  of  the  expression, 
node2  is  the  right _argument  of  the  expression, 
nodel  is  undefined. 
node2  is  undefined,  and 
nodel  is  the  current_node; 

If  given  a  string  is  the  command. 

the  string  is  a  member  of  the _Iist  of  "-+■  ",  "x".  and  "/", 

an  expression  is  the  current_node,  and 
the  expression  is  not  undefined 

then  "defined  node "(  procedure )  is  displayed_with_return; 

1  begin  Command  ! 

If  given  "begin"  is  the  command,  and 
given  any_node  is  the  current_node 

then  an  object  is  established  as  a  newjroot; 

If  given  an  expression  is  a  new_root 

then  the  expression  is  a  root_node, 
the  expression  is  undefined,  and 
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the  expression  is  the  current_node: 

!  root  Command  ! 

If  given  "root"  is  the  command. 

given  any_node  is  the  current_node,  and 
an  expression  is  the  root_node 

then  the  expression  is  the  current _node,  and 
'%how"is  the  command: 

!  Test  driver  ! 

If  given  Nil  is  the  script 

then  'Script  completed"  ( procedure )  is  displayed_with_return 

Else  if  given  a  list  is  the  script,  and 
(the  first  (function)  of  the  list  = 

the  first  (function)  of  the  list  =  ’Val") 

then 

begin 

"  ...  "  (procedure)  is  displayed; 

the  first  (function)  of  the  rest  (function)  of  the  list 
(procedure)  is  displayed; 

the  first  (function)  of  the  list  (procedure)  is 
displayed_with_r<*turn; 

the  first  (function)  of  the  list  is  the  command, 

the  first  (function)  of  the  rest  (function)  of  the  list  is  the  argument,  and 

the  rest  (function)  of  the  rest  (function)  of  the  list  is  the  pending_script 
end_b!ock, 

Else  if  given  a  list  is  the  script 
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then 


X< 


CH 


"  "(procedure)  is  displayed; 
the  first  (function)  of  the  list  (procedure)  is 
displayed_w  ith_return; 

the  first  (function)  of  the  list  is  the  command,  and 
the  rest  (function)  of  the  list  is  the  pending_script 


end  block; 


If  given  a  list  is  the  pending_script.  and 
something  is  not  the  command 
then  the  list  is  the  script; 


end  rules. 


activate  the  rules  ! 


The  PIl_rules  (procedure)  are  activated. 


Nil  is  the  current  node. 


'PI-1  System  loaded"  ( procedure)  is  displayed_with_return . 


-  *  **'  fc*V  W***  , 
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APPENDIX  C  Transcript  of  f!  Session 


The  following  is  a  transcript  of  an  fl  session  illustrating  the  operation  of  the  prototype  programming 
environment  shown  in  Appendix  A.  The  assertion  'Script  (testscript) '  causes  the  commands  in 
testscript  to  be  executed  in  order.  Each  command  is  printed  on  a  separate  line,  followed  by  whatever 
output  is  generated  by  the  programming  environment  This  transcript  was  produced  by  the  McArthur 
interpreter  McArthur84  . 


OMEGA-1  11  30/84 


Use  Cntl-D  or  exit{}  to  quit. 


For  help,  enter  help{"?"}. 


To  report  a  bug,  enter  Bugs{}. 

PI-1  System  loaded 
>  Script  (testscript) . 

begin.  -  ,  /,  «.  3.  next,  #,  0,  out,  out.  in,  next,  4f,  1,  root,  evaluate,  show,  in,  in,  next, 
delete.  #.  1,  root,  abort,  evaluate 
...  begin 


...  next 


(3/0) 
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( (3  /  0)  <  expr> 

..in 
(3  0) 

...  next 

<  expr> 

...  1* 

1 

...  root 

((3/0)  +  1) 

...  evaluate 
division  by  zero 
...  show 

(3  /  0) 

...  in 

3 

...  next 

0 

...  delete 

<  expr> 

...  1# 

1 

...  root 

((3  /  1)  +  1) 

...  abort 
aborted 
...  evaluate 

4 

Script  completed 
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